Network Load Balancer로 SNMP 서비스에 대한 부하 분산
안녕하세요 클래스메소드 김재욱(Kim Jaewook) 입니다. 지난「Application Load Balancer에 대해」에 이어서 이번에는 Network Load Balancer를 구축하고, SNMP 서비스에 대한 부하 분산을 해봤습니다.
현재 환경
현재 환경은 다음과 같습니다. ELB-VPC에는 퍼블릭 서브넷에 2대의 EC2 인스턴스와 Application LoadBalancer를 생성했고, Application LoadBalancer 리스너의 경우 DevGroup와 MGTGroup을 추가해서 ELB-EC2-1에는 dev/* 경로의 파일을 실행시키고, ELB-EC2-2에는 mgt/* 경로의 파일을 실행시키도록, 경로 기반 라우팅을 통한 부하 분산을 하고 있습니다.
자세한 환경은 아래 블로그를 참고해 주세요
NLB를 사용한 로드 밸런싱
NLB 생성 및 타겟 그룹 설정
왼쪽 로드 밸런싱 카테고리에서「로드밸런서」를 클릭하고, 「Load Balancer 생성」버튼을 클릭합니다.
Network Load Balancer를 선택합니다.
로드 밸런서 이름은 NLT-TEST로 해주고, Scheme를 선택해야 하는데 Internet-facing은 인터넷을 통해 외부에서도 로드 밸런서로 접근할 수 있도록 하는 것 이고, Internal은 같은 VPC내의 클라이언트만 접근 가능합니다.
VPC는 앞서 생성했던 ELB-VPC를 선택해 주고, 서브넷도 ap-northeast-1a, ap-northeast-1c의 가용 영역에 있는 서브넷을 선택하면 됩니다.
이어서 타겟 그룹 생성을 위해「Create target group」을 클릭합니다.
- 타겟 그룹 이름은「NLB-TG」로 입력합니다.
- SNMP를 사용할 생각이기 때문에 프로토콜와 포트 번호는 UDP 161번을 선택합니다.
- VPC는 로드 밸런서가 생성될 ELB-VPC를 선택합니다.
- Health check의 경우 TCP, HTTP HTTPS만 가능합니다. 현재 ELB-EC2-1, ELB-EC2-2는 HTTP 서비스가 동작 중이기 때문에 HTTP 서비스를 상태 확인을 위한 용도로 활용해서 인스턴스 정보를 파악합니다. 여기서 상태 검사의 경우 요청을 보내고 응답을 확인하는 개념인데, UDP의 경우 단반향 통신이기 때문에 상태 검사에는 적합하지 않습니다.
「Advanced health check settings」에서 포트를 80번 포트로 재정의합니다. 여기서 재정의를 하지 않을 경우 타겟 그룹의 프로토콜이 UDP 일 때 unhealthy 상태가 되어버립니다.
이어서 ELB-EC2-1, ELB-EC2-2를 모두 선택해서 타겟 그룹에 포함 시키고, 타겟 그룹 생성을 끝마칩니다.
마지막으로 로드 밸런서의 프로토콜과 포트 번호를 UDP, 161로 선택한 다음, 이전에 만들어두었던 타겟 그룹을 선택해서 로드 밸런서 생성을 끝마칩니다. Network Load Balancer에서는 Application Load Balancer와는 다르게 보안 그룹을 설정하지 않는데, Network Load Balancer는 인스턴스 레벨에서 보안 그룹을 제어하기 때문입니다.
마지막으로 타겟 그룹을 확인해 보면「healthy」인 것을 확인할 수 있습니다.
NLB 테스트
snmpget -v2c -c public NLB-TEST-bf83f08913aae423.elb.ap-northeast-1.amazonaws.com system.sysDescr.0
snmpget 명령어를 사용해서 network loadbalancer가 부하 분산 되는지 확인해 봅시다.
확인해 보면, UDP 161번 포트로 전달하는 SNMP 요청을 network loadbalancer가 ELB-EC2-1, ELB-EC2-2로 부하 분산 하고 있는 것을 볼 수 있습니다.
tcpdump udp port 161 -nn
ELB-EC2-1 인스턴스에서 해당 명령어를 통해 IP를 어떻게 전달하는지 확인해 봅시다.
18.179.61.105는 출발지 IP를 의미하는데, 18.179.61.105는 snmpget을 실행 했던 My-EC2의 IP 주소 입니다. 즉 NLB는 출발지의 IP를 사용자의 퍼블릭 IP를 그대로 유지해서 전달합니다. 하지만 ALB는 출발지 IP를 사용자 IP가 아닌 ALB 자기 자신의 로컬 IP로 통신합니다. 하지만 클라이언트의 IP를 보존하지 않으면 어떤 대상이 접근했는지 알 수 없기 때문에 ALB에서는 X-Forwarded-For 헤더라는 곳에 클라이언트의 IP를 담아서 전달합니다.
X-Forwarded-For은 HTTP 헤더 필드 중 하나. HTTP 프록시 서버 또는 부하 분산 장치를 통해 웹 서버에 연결하는 클라이언트의 소스 IP 주소를 특정하기위한 사실상의 표준이다.
ALB와 NLB의 최종 아키텍처는 다음과 같습니다.
